A file server is a computer that provides file service relating to the organization of information on storage devices, such as disks. The file server or filer includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the disks. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directory may be implemented as a specially-formatted file in which information about other files and directories are stored. A filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the filer over the network.
As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a storage system that manages data access requests and may implement file system semantics in implementations involving file servers. In this sense, the Data ONTAP™ storage operating system, available from Network Appliance, Inc. of Sunnyvale, Calif., which implements a Write Anywhere File Layout (WAFL™) file system, is an example of such a storage operating system implemented as a microkernel. The storage operating system can also be an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
Disk storage is typically implemented as one or more storage “volumes” that comprise physical storage disks, defining an overall logical arrangement of storage space. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example). Each volume is associated with its own file system and, for purposes hereof, volume and file system shall generally be used synonymously. The disks within a volume are typically organized as one or more groups of Redundant Array of Independent (or Inexpensive) Disks (RAID). RAID implementations enhance the reliability/integrity of data storage through the redundant writing of data “stripes” across a given number of physical disks in the RAID group, and the appropriate caching of parity information with respect to the striped data. As described herein, a volume typically comprises at least one data disk and one associated parity disk (or possibly data/parity) partitions in a single disk) arranged according to a RAID 4, or equivalent high-reliability, implementation.
Computer and file server architectures differ in their method of storing a sequence of bytes in computer memory. Each byte traditionally carries 8 bits of information. However, to store and process larger numbers, for example, 16-bit or 32-bit quantities, microprocessors and computers store a sequence of bytes together to produce a desired-sized number. The two most common methods of storing these multi-byte sequences are termed “big endian” and “little endian”. In a big-endian computer, the most significant value in the sequence is stored first. Conversely, in a little-endian computer, the least significant value is stored first. The least significant value is a byte of a sequence that represents the smallest quantity. For example, given the two-byte hexadecimal number 4F52, the least significant byte is the “52” byte.
With regard to storing these multi-byte sequences, “first” means the lowest storage address. For example, given the two byte hexadecimal number 4F52, a big-endian computer would store this number in memory as 4F52. If, for example, the “4F” byte was stored at memory address 1000, the “52” byte would be stored at memory address 1001. Conversely, in a little-endian computer, this number would be stored as 524F, with the “52” byte stored at memory address 1000 and the “4F” byte stored at memory address 1001.
In both big and little-endian computers, the bits within each byte are traditionally stored in big-endian format. While it is possible to have a little-endian bit order, most conventional central processing units and microprocessors are currently designed for a big-endian bit order.
The endianness of a particular computer or filer server is particularly relevant when that computer is exchanging specific types of data with a computer or file server of a differing endianness. By “endianness” it is meant the byte order that a particular computer, file server or network device utilizes, for example big or little-endian. Many data transfer protocols and file formats of a set endianness for use with a computer performing any translations as needed. However occasions do arise when a computer needs to know the endianness of another computer. One example of this is a use of remote direct memory access (RDMA) through certain communication links such as a virtual interface (VI) connection. Remote direct memory access enables data to be passed between storage and memory over a network with little host processor intervention. The term “virtual interface” refers to an industry-standard interface between high performance network hardware and computer systems. The architecture for the virtual interface (VI) is defined in VIRTUAL INTERFACE ARCHITECTURE SPECIFICATION, VERSION 1.0, published in collaboration between Compaq Computer Corporation, Intel Corporation and Microsoft Corporation, which is hereby incorporated by reference. To use the RDMA read/write capabilities implemented under the VI architecture, the source computer must supply to the VI interface the source of the data to be transferred and the destination address on the remote computer for the data. Under the VI architecture specification, this remote address must be organized in the proper endianness of the remote computer. In a homogeneous networking environment, where all computers involved share the same endianness this requirement is easily met. However, a need arises to determine the proper endianness of the computer to which a different computer is connected when all the computers in a given network do not share the same endianness. One technique for determining the endianness a computer connected to another computer via a VI connection is described in U.S. patent application Ser. No. 10/061,626 filed on Feb. 1, 2002, by Philip J. Christopher entitled SYSTEM AND METHOD FOR USING AN ENDIAN-NEUTRAL DATA PACKET TO DEFINE SUBSEQUENT DATA PACKET BYTE-ORDER, which is hereby incorporated by reference.
The Direct Access File System (DAFS) is a file access and management protocol designed for local file sharing or clustered environments. The primary goal of DAFS is to provide clients with high-speed file and system access with the lowest possible cost for the client. DAFS is defined in DAFS: Direct Access File System Protocol, Version 1.0, by Network Appliance, dated Sep. 1, 2001, the contents of which are hereby incorporated by reference. The DAFS protocol takes advantage of system and networks that provide Direct Access Transport (DAT) capabilities that allow for direct memory to memory data transfer. DAT includes, inter alia, the capability of direct memory to memory data transfers such as remote direct memory access (RDMA). The above-incorporated DAFS protocol defines file access operations that use remote memory-to-memory copying other high-performance data transport operations supported by DAT, including the use of RDMA over Direct Access Transport systems, such as a VI connection or over an InfiniBand Trade Association's InfiniBand™ network. RDMA capabilities are incorporated into a VI implementation. A Virtual Interface Provider Library (VIPL), which implements VI on a computer, includes dual commands for many operations, including a traditional inline data movement command and a RDMA data movement command. The inline data movement commands execute by breaking a block of data to be transferred into appropriate sized packets and transmitting the packets over the network connection. The RDMA variants of the data movement commands utilize the RDMA capabilities of VI to more efficiently move larger blocks of data from computer to computer.
Under the DAFS protocol, packets that are exchanged between clients and servers are defined as discrete structures instead of being-stream encoded. For example, the structures are sequences of data elements that can be of varying sizes. As an additional technique to reduce the processing cost to the client, the DAFS protocol requires that multi-byte data elements are encoded using a client-specified byte order, which is presumed to be native to the client. Thus, multi-byte data elements sent in by the server to the client must be converted to this client-specified byte order.
In known byte-swapping implementations, each data structure or function utilizes a specifically coded byte-swapping routine. Such byte-swapping routines may be implemented in either hardware or software. A noted disadvantage of the use of a set of specifically coded functions for byte swapping is the amount of storage required for the various routines. As each data structure has an associated routine, the storage space required to hold the various byte-swapping routines increases with the number of data structures that could be byte swapped. Additionally, the use of specifically coded and static functions to perform byte swapping does not permit easy modifications to the swapping routines should a change in the data structures occur.